Солдатов в Телеграм

Когда клиентская база достаточно большая, дополнительный объем в 10к новых эндпоинтов в мониторинг не требует дополнительных ресурсов. Однако 100 клиентов по 100 - совсем не одно и то же, что 10 клиентов по 1000 или, тем более, 1 клиент с 10 000 эндпоинтов! И причина тому - необходимость адаптации. После этой заметки, думаю, станет понятнее почему малое количество крупных клиентов на долго проще в обслуживании множества мелких с короткими периодами обслуживания.

99% ложных срабатываний связаны с особенностями заказчиков, поэтому для огромного количества правил обнаружения есть клиентские фильтры, - чем больше клиентов, тем больше клиентских фильтров. Фильтрами надо управлять, отслеживать что они фильтруют фолсу и, что еще важнее, - не фильтруют инциденты. В общем, создание фильтра - это только начало, далее следует нелегкий процесс управления клиентскими фильтрами. Средняя продолжительность адаптации одного клиента среднего размера (до 10 000 эндпоинтов) составляет 1-2 месяца, т.е. за это время большая часть его контекстной фолсы будет отфльтрована (== фолсящие на сети клиента правила будут адаптированы), далее эта адаптация будет продолжаться постоянно, догоняя процесс управления изменениями в ИТ-инфраструктуре клиента. На период адаптации трудоемкость по обработке алертов с клиента увеличивается примерно в 2 раза, как раз за счет необходимости реализации адаптации (== фильтровать контекстную фолсу).

Понятно, что если фильтры не делать, то контекстной фолсы будет очень много, и это будет сильно снижать эффективность работы команды: все будут заняты разбором ложных срабатываний, что не может не отразиться на усталости\утомленности и, в конечном счете, результате работы. Но это в долгосрочной перспективе. В краткосрочной перспективе мы имеем х2 трудоемкости без очевидного выхлопа по качеству обнаружения.

Простота подключения к MDR делает возможным множество пилотов, поэтому, усредненно по году по миру 20-30% объема мониторинга - пилоты. Продолжительность пилота - 1 месяц... и здесь следует заметить, что а) поскольку не всегда есть уверенность, что клиент после пилота станет коммерческим клиентом, адаптация на пилоте делается по-минимуму, не в указанные выше х2 трудоемкости, б) месяца пилота недостаточно чтобы закончить процесс адаптации, в) даже если уложимся в месяц, увидеть результат в долгосрочной перспективе - не судьба😔. Как результат, фолсы на пилоте очень много и с ней приходится мириться, ввиду всего описанного. Следовательно, совокупная конверсия детектирующей логики на пилотах ощутимо ниже, а если пилоты берутся во внимание при расчете общей конверсии по всем клиентам (и пилотам, и коммерческим), то описанная ситуация с пилотами приводит к снижению общей конверсии.

Дзен | Статьи

Адаптация

Статья автора «REPLY-TO-ALL Information Security Blog» в Дзене ✍: Ну раз Нассиму Николасу Талебу можно одну из глав книги "Антихрупкость" позже расписать на целую книгу "Рискуя собственной шкурой...

www.tg-me.com/us/Солдатов в Телеграм/com.soldatov_in_telegram/175

595 viewsFeb 27, 2024 at 20:11

Когда клиентская база достаточно большая, дополнительный объем в 10к новых эндпоинтов в мониторинг не требует дополнительных ресурсов. Однако 100 клиентов по 100 - совсем не одно и то же, что 10 клиентов по 1000 или, тем более, 1 клиент с 10 000 эндпоинтов! И причина тому - необходимость адаптации. После этой заметки, думаю, станет понятнее почему малое количество крупных клиентов на долго проще в обслуживании множества мелких с короткими периодами обслуживания.

99% ложных срабатываний связаны с особенностями заказчиков, поэтому для огромного количества правил обнаружения есть клиентские фильтры, - чем больше клиентов, тем больше клиентских фильтров. Фильтрами надо управлять, отслеживать что они фильтруют фолсу и, что еще важнее, - не фильтруют инциденты. В общем, создание фильтра - это только начало, далее следует нелегкий процесс управления клиентскими фильтрами. Средняя продолжительность адаптации одного клиента среднего размера (до 10 000 эндпоинтов) составляет 1-2 месяца, т.е. за это время большая часть его контекстной фолсы будет отфльтрована (== фолсящие на сети клиента правила будут адаптированы), далее эта адаптация будет продолжаться постоянно, догоняя процесс управления изменениями в ИТ-инфраструктуре клиента. На период адаптации трудоемкость по обработке алертов с клиента увеличивается примерно в 2 раза, как раз за счет необходимости реализации адаптации (== фильтровать контекстную фолсу).

Понятно, что если фильтры не делать, то контекстной фолсы будет очень много, и это будет сильно снижать эффективность работы команды: все будут заняты разбором ложных срабатываний, что не может не отразиться на усталости\утомленности и, в конечном счете, результате работы. Но это в долгосрочной перспективе. В краткосрочной перспективе мы имеем х2 трудоемкости без очевидного выхлопа по качеству обнаружения.

Простота подключения к MDR делает возможным множество пилотов, поэтому, усредненно по году по миру 20-30% объема мониторинга - пилоты. Продолжительность пилота - 1 месяц... и здесь следует заметить, что а) поскольку не всегда есть уверенность, что клиент после пилота станет коммерческим клиентом, адаптация на пилоте делается по-минимуму, не в указанные выше х2 трудоемкости, б) месяца пилота недостаточно чтобы закончить процесс адаптации, в) даже если уложимся в месяц, увидеть результат в долгосрочной перспективе - не судьба😔. Как результат, фолсы на пилоте очень много и с ней приходится мириться, ввиду всего описанного. Следовательно, совокупная конверсия детектирующей логики на пилотах ощутимо ниже, а если пилоты берутся во внимание при расчете общей конверсии по всем клиентам (и пилотам, и коммерческим), то описанная ситуация с пилотами приводит к снижению общей конверсии.

BY Солдатов в Телеграм